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microcoded control to translate a packet from one protocol to 
' reading of information from information sources (including 
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MUl^TmOTOTOf P ACKFT TRANSLATOR 

Field Of the Invi-iitf™ 

This invention relates to communication networks, and more particularly, to apparatus 
and methods for translating information packets from one network protocol to another 
network protocol. 

Discussion of tfo Related Arj 

Computer communication networks have proliferated in order to enable the sharing of 
computer resources over a computer network. A network for permitting communication may 
be referred to as a local area network or "LAN." LAN refers to an interconnection data 
network that is usually confined to a moderately sized geographical area, such as a single 
office building or a campus area. Larger networks are often referred to as wide area networks 
15 or "WANs." 

Networks may be formed using a variety of different interconnection elements, such as 
unshielded twisted pair cables, shielded twisted pair cables, coaxial cable, fiber optic cable, or 
even wireless interconnect elements. The configuration of these cabling elements can follow 
one (or more) of many topologies, such as star, ring or bus. 

20 hi addition, a number of different protocols for accessing the networking medium have 

evolved. Examples of various network protocols include FDDI, Ethernet (and multiple 
Ethernet communication protocols), ATM, token ring (and multiple token ring 
communication protocols) and ISDN. One particularly attractive communication network is 
described in U.S. Patent No. 5,485,455, issued January 16, 1996. 

25 The total number of installed communication networks has grown explosively. The 

number of communication protocols also continues to expand. Consequently, there are a great 
number of installed networks, many using different protocols. As the number of networks and 
network protocols has expanded, so has the desire to expand the scope of network coverage. 
The result is a desire to send packets trcm networks iisiiig om 

30 networks using other communication protocols. 

A communication within a network is referred to as a "packet" (''packet" and "data 
• packet" are intended to include traditional data packets and any functional equivalent, whether 



referred 10 in the art as "cells," "datagrams," or the like). A packet intended for use with one 
protocol cannot necessarily be used in a network that follows a different protocol. 
Accordingly, some form of translation is required when sending packets between networks 
that follow different communication protocols. 

FIG. 1 illustrates an example of a prior an connection between networks. The first 
network 10 forwards communications within the network 10 according to one communication 
protocol. The second network 1 1 forwards communication packets around the network 1 1 
using a different communication protocol. Accordingly, if a packet needs to be sent from the 
first network 10 to the second network 1 1, a translation needs to be made. According to the 
prior art, a translation unit 12 is included for translating packets from the communication 
protocol of the first network 10 to the communication protocol of the second network II ; and 
vice versa. 

For design of the translator 1 2. the prior art follows one of two approaches. In the first 
approach, a general purpose computer processor is used to do the translauons. The processor 
generally stores the packet in memory, manipulates the packet within that memory to conform 
to the new protocol and then outputs the translated packet. 

The second approach is to design a custom hardware machine to perform the 
translation. For this solution, a state machine is hard coded to perform each translation from 
one formal to the other. In the event that the translator 12 must translate from multiple 
formats to multiple formats, a fast hard coded translator must be designed and implemented 
for each translation. While common parts of similar translauons may be combined to 
decrease circuitry, this adds significantly to the complexity of hardware verification. The hard 
coded state machine is usually implemented on an application specific integrated circuit 
(ASIC) or using a programmable logic device (PLD, such as field programmable gate arrays 
or complex programmable logic devices). 
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Throughoul the description and claims of this specification, the word 
"comprise" and variations of the word, such as "comprising' and comprises", is 
not intended to exclude other additives or components or integers. 

Summary of the Invention 

According to one aspect of the present invention there is provided a 
translator unit for translating a first packet formatted according to a first protocol 
having a first header format into a second packet formatted according to a 
second protocol having a second header format different from the first header 
format, the translator unit comprising: 

an input memory; 

at least one information source; 

an output memory; 

a connection circuit, coupled to the input memory, the information source 
and the output memory, to selectively connect the input memory and the 
information source to the output memory; and 

a microcoded control unit coupled to the connection circuit to control 
translation of the first packet into the second packet. 

In this embodiment, the microcoded control unit may include a pipeline 
unit coupled to the connection circuit. 

According to a further aspect of the present invention there is provided a 
pipelined control unit for reading data, comprising: 

a first memory having a first read latency; 

a second memory having a second read latency, longer than the first 
read latency; 

a pipeline unit having a first stage and a second stage; 

a circuit, coupled to the pipeline unit, the first memory and the second 
memory, to initiate read cycles from the first memory based on a first instruction 
in the second stage of the pipeline, and to initiate read cycles from the second 
memory based on a second instruction in the first stage of the pipeline. 

According to a still further aspect of the present invention there is 
provided a method of translating an original packet from a first protocol to a 
different second protocol, comprising steps of: 
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loading a first memory with a plurality of sets of microcode instructions, 
each set being designed to perform a different network communication protocol 
translation; 

receiving the original packet and storing the packet in an input memory; 
5 selecting one of the sets of microcode instructions, based on a first 

identity of the first protocol and a second identity of the second protocol; and 

translating the original packet into a translated packet by executing the 
selected set of microcode instructions, said translating step including a step of 
selectively connecting the first memory and the input memory to an output 
10 memory. 

According to a still further aspect of the present invention there is 
provided a method of translating an original packet into a translated packet that 
is different from the original packet, comprising steps of: 

loading an instruction memory with a set of instructions; 
15 loading at least a header portion of the original packet into an input 

memory, the input memory having a first read latency; 

providing an information source; 

providing an output memory to store the translated packet; and 
sequentially, selectively connecting the input memory and the information 
20 source to the output memory, based on the set of instructions. 



Brief Description of the Drawings 

Preferred embodiments of the present invention will now be described 
25 with reference to the accompanying drawings wherein: 

FIG.1 illustrates a prior art setting for translation of packets between two 
communication networks; 

FIG. 2 illustrates one embodiment of a translator unit according to the 
30 present invention; 

FIG. 3 Slustrates translation from an original packet to a translated packet 
according to one embodiment of the present invention; 

FIG. 4A illustrates one use of a translation unit according to the present 
invention; 
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FIG. 4B illustrates a second embodiment using a translator according to the 



present 



FIG. 4C illustrates a third embodiment using a translator unit according to the present 
invention to translate packets sent among three networks; 
5 FIG. 5 illustrates the circuit for a multi-protocol translator according to one 

embodiment of the present invention; 

FIG. 6 illustrates one embodiment of a pipeline unit for use in the multi-protocol 
translator of FIG. 5; 

FIG. 7 A illustrates a packet formatted according to the L2 VLAN tagged Ethernet 
10 dixie communication protocol; 

FJG. 7B illustrates the packet of FIG. 7A, translated to the ATM Forum LANE 2.0 
communication protocol; 

FIG. 8 illustrates a method of translating a communication packet according to one 
embodiment of the present invention; 
15 FIG. 9 illustrates another embodiment of a multiprotocol translator according to the 

present invention, including a double pipeline unit; 

FIG. 10 illustrates another embodiment of a rnulti -protocol translator according to the 
present invention, including a quad pipeline; 

FIG. 1 1 A illustrates one step of translating the packet of FIG. 7 A into the packet of 
20 FIG. 7B. using the circuit of FIG. 10; 

FIG. 1 1 B illustrates the partial results of the translation, after the step shown in FIG 

II A; 

FIG. I2A illustrates a subsequent step in translating the packet of FIG. 7A into the 
packet of FIG. 7B, using the circuit of FIG. 10; 
25 FIG. 1 2B illustrates the partial results of the translation, after the step illustrated in 

FIG. 12A is performed; 

FIG. 13A illustrates a next step in translating the packet of FIG. 7A into the packet of 
FIG. 7B, using the circuit of FIG. 10; 

FIG. I4A ilrustiates a next step in translating the packet ofFIG. 7A into the packet of 
30 FIG. 7B, using the circuit ofFiG. 1 0; 

FIG. 14B illustrates the partial results after the step illustrated in FIG. I4A; 



20 



30 



^ FIG. 15A illusttues a next «ep * translating a packet of FIG. 7A into the packet of 
KG. 7B. using the circuit of FIG. 10; 

5 

Detailed TV^jp^.n fff fr, Inv,,,^ 

. While the use of genera, purpose processors to perform translations is flexible, the 
sys^c^ot^op^^^^^^^ Accordingly, a processor 
^^^-beab^^^eperfonnance^^^^^^ 
» when there is a lot of traffic through the translator. 

. The alternative, hard coded aate machines, can be quite expensive. In addition, they 
aretnirexible. If any change is required, a new design musl be made . ^ is a signifi ^ 
problem because conununication protocols change frequency and new protocols arc 
protnu.ga.ed with some frequency. Moreover, the designs typically are difficult m modify to 
apply to new environments o: where additional translations need to be performed by th e 
translator 12 of FIG. I. 

One or more embodiments of toe present rentier, achieve a variety of advantages 
over these prior art systems. Cettam embodiment of Represent invention can achieve one 
more of the foUowing goals: the embodiment is fas, being equivalent or close to speed to 
custom hardware based elation; real time procKsor mtervention ^ ^ ^ ^ 
transition is unnecessary, the translator can be adapted to perform new translations without 
e^venewdeveiopment; toe design is fiexibleand can be configured for multiple protoco, 
translations; me translator is field "Pgraoable (i.e.. raises o, new transitions can be 
addressed with a field upgrade); the imp.ementa.ion is compact; and the .rancor is 
scalable - capable of performing tradc-ofis between speed and complexly. 

FIG. 2 frustrates a simplex translator 28 according to one embodiment of the present 
mvention. In a simp.ex translator, packet am tnutstaed only 0De Thus>apa£te 
would be recetved fiom a firs, network on the network interface 20n, translated by to* 
tmnsUmr^a^c^toasecondnetworkbync^ricintcrfaceJOb. Thenctwwt 
■n.erfaces 20a, 20b may be of me same form commonly used in toe art to receive and send ' 
datopackcts to/fiom a network. For example, the neurit interface may be part ofknown 
et swrtcbes. routers, bridges or jus. a physical port with associated hardware. 

AMEND© SHEET 



or 

a 



^crfes the eattre path through a network In the alternative the header 22, m • 

acaaer 22a. The packet may aiso include a trailer 22c Both the h«.rf« 

^p.yafW fl «h e ade r .whe re ^U»o^ asiUustraledal22b 

^ ^ mem0ry> CaPaWe ° f a0rinE ^ ^ arrive from netwl 

interface 20a but have not yet been translated 

r^Z'^^^^^^^^^etcanbe^. 

SSitT ^^^^^^---orv^. Technic 
for identifying what particular translation is required are mrr _ t , . 
^TR%. 0 . e __ tDCo . ^ n . . ^ 1TCd ^ "^"j ^own. Where more than 

O ^one protocol translate B reared, the m^protoco, translator (MPT) 26 performs the 
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appropriate translation based on the information provided by the controller 24. These 
functions of the controller are described in greater detail below. 

The controller 24 can be implemented in one of many ways. The controller will most 
likely be implemented using ASICs or programmable logic devices, for speed. A genera! 
processor could also be used to perform this function, as the amount of processing required to 
initiate packets is relatively small and delay incurred from use of a general purpose processor 
is minimal. 

When an incoming packet 22a-22c has been received and stored in the input memory 
21a, and after the controller has determined what translation to perform, the controller can 
begin the translation process. 

In the embodiment of FIG. 2, the translation process is performed by two separate 
elements the multi-protocol translator (MPT) 26 and the direct memory access (DMA) 
controller 27. The MPT 26 translates the header and trailer information from the first protocol 
(e.g., packet 22a-22c) into the header and trailer information for the new packet (23a-23c). 
The translated packet is stored in output memory 21b, and when complete is forwarded to the 
network interface 20b for transmission across the second network. 

The MPT 26 could also forward the data portion 22b of the incoming packet into the 
output memory 2 1 b. (This may be particularly useful where a trailer or other field needs to be 
formulated based on the contents of the entire packet, such as a check-sum field or other error 
detection or correction fields. By passing the data through the MPT, the applicable field can 
be accumulated as the output memory is written.) Because no change is required to the 
payload for most translations, however, in many cases this may be done using only a direct 
memory access CDMA") controller 27. Thus, the DMA controller 27 can be forwarding data 
(payload) into the output memory while the MPT 26 is setting up the appropriate header and 
trailer information for the translated packet. 

FIG. 3 illustrates the translation process from one packet (3 1 -33) to a packet using a 
different communication protocol (34-37). The first packet includes a header 3 1 , the 
remainder of the packet being data 33. As shown, the MPT translates the header of the first 
packet3! into the new translated header 34. The MPT may also forward some of the payload 
32 into the new translated packet as shown at 35. The DMA controller 27 would then handle 
the transfer of the remainder of the payload 38. (The DMA controller 27 may include also a 
mechanism to alter byte alignment when multiple bytes are read from an input memory and/or 
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multiple bytes written lo an output memory, as explained with reference to the storage 
alignment units of FIGs. 9 and 10.) 

The MPT might be configured to forward some of the data 32 to the new packet 35. to 
accommodate the possibility of variable length headers. For some communication protocols, 
the length of the header varies. One approach to resolving this is to have the system controller 
look up the header length and have the MPT process only the header, while the DMA 
transfers only data. Another solution, as illustrated in FIG. 3, is to take the maximum header 
size (here, equivalent to fields 31 and 32 of FIG. 3, which, in this example, includes some data 
because, in FIG. 3, the actual header is smaller than the assumed maximum header size) and 
always run that portion of an incoming packet through the MPT. In this case, while some data 
is unnecessarily transferred through the MPT, there is no need to perform an additional table 
lookup to determine where the header/data boundary is for the applicable incoming packet. 

The embodiment of FIG. 2 provides for unidirectional translation. That is, packets are 
only received (and not transmitted) on network interface 20a, translated by the translator 28, 
and transmitted (and no packets received) from network interface 20b. To apply the translator 
28 of FIG. 2 to the network of FIG. 1 , two translator units 28 would be required. The first 
translator unit would handle packets traveling from the first network 10 to the second network 
11 The second translator would handle packets traveling in the opposite direction (as in 
FIG. 4A). 

The embodiment of FIG. 2 can be modified to handle bidirectional traffic. This can be 
achieved in at least two different ways. First, additional connections could be provided to 
permit translation both from memory 2 1 a to memory 2 1 b and vice versa. Thus, the DMA 
controller 27 would be capable of transferring data from the input memory 21a to the output 
memory 2 1 b as before, and would also be able to directly transfer data from the memory 21b 
to the memory 2 1 a when packets are being sent from network interface 20b to network 
interface 20a. Similarly, the MPT 26 would be capable of receiving information for 
translation from both memories 2 1 a and 2 1 b, and writing the translated header (or trailer) 
information to the other opposite memory. 

Another possibility is io use input memory 21a only as an input buffer and output 
memory 21b only as an output buffer, but to permit both network interface 20a and 20b to 
provide incoming packets to the input memory 21a and allow output memory 21b to provide 
outgoing packets to both network interface 20a and 20b. In this case, the embodiment of FIG. 
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2 could remain the same, but adding switches, multiplexers or the equivalent to permit 
multiple inputs and outputs for the input and output memories 21a and 21 b. 

FIG. 4A illustrates use of two iinidirecUonal processors for translation between two 
networks. Thus, packets sent from a first network 41 to a second network 42 are translated by 
5 a translator 44. Packets sent from the second network 42 to the first network 4 1 are sent 
through a separate translator 45. This permits parallel processing, at the expense of added 
hardware. 

FIG. 4B illustrates use of a single translator unit 46, as described above, to send 
packets both from the first network 41 to the second network 42 and vice versa. In this case, 
10 the translator must perform two transactions - NWI to NW2 and NW2 to NW 1 . 

FIG. 4C illustrates use of a single translator 47 with additional networks. In this 
embodiment, the first network 4 1 . second network 42 and third network 43 each have a 
different communication protocol. The multi-protocol translator 47 can receive packets from 
all three networks, translate them to the appropriate protocol for the destination network, and 

15 forward the packet accordingly. Of course, similar designs using any number of networks 
could be implemented. 

Referring again to FIG. 2, the multi-protocol translator 26 should preferably be fast, 
flexible, programmable to handle multiple (and new) translations and upgradable without 
having to redesign the entire system. 

20 FIG . 5 illustrates one embodiment of a multi-protocol translator according to the 

present invention. In general, the multi-protocol translator shown in the embodiment of FIG. 
5 works as follows. The original frame (or frame to be translated) is held in memory 53a. 
Substitute information to be inserted into the translated frame is held (or produced) in other 
mechanisms. In FIG. 5, these information sources are the two FIFO memories 54 and 55. To 

25 produce a translated frame, data is selectively passed from the input memory 53a, information 
sources 54 and 55, and from instruction operands, into the output memory 58. The outgoing 
frame is then stored in the output memory 58. The appropriate data is passed through a 
multiplexer 56 into the output memory. A microcoded, pipelined control unit 59 controls the 
reading of the memories 53a, 54 and 55 and the passing of data to the output memory 58 

30 through the multiplexer 56. Thus, in FIG. 5, the translator has an input memory 53a, in which 
the onginal frame (the frame to be translated) is stored. This input memory 53a may receive 




internal to the multi-protocol translator. 

In the embodiment of FIG. 5, an address control unit 53b controls what memory 
^^^mthempmme^ftr^in^^^^^^,^^ 
5 may farther control the input memory for writing the original frame into the memory ascould 
be readily designed by one of skill in the art based on the disclosure provided herein. 

. ^^aboirtcludestwofiw-m^^ ^ 
memories contain new header information that may be required in one of me tmnslations tha, 
tfcMPTcan perform, lens, the two FIFOs 54, 55 provide alternative information that can be 
.0 used to replace ox sopp.cmen, the header (or trail,,) ia/onnarion in the origmai W, during 
translate Of course, other mecharosms and other (oms ormaaoTy ^ „ ^ „ ^ 
ofFIFOs 54 and 55. More complicated information sources might include mechanisms ,o 
generate new fields based on previous fields, such as a check-sum or other error detection or 
cotrecnon field. The number of information sources may also vary, depending on what 
l J translation^) the MPT can perform. 

A dump memory 57 may be inctuded. The dump memory would serve to save 
mformationfiom the original ^ (or me er^ original r^e) for system admimstratior, 
thagnosttc purposes, or for some other form of processing. Addressing of the dump memory 
57 may be controlled by an address control unit 57a. 

A multiplexer 56 selectively provides the appropriate data from the input memory 53a. ' 
FIFO 54 and 55 or from the confer, to the output memory 58. Of course, mechanisms 
other than multiplexers could be used to perform the same function. 

The output memory 58 can be any suitable memory (including registers, random 
access memory, etc) to hold the translated frame(orthe portion of tr* frame being translated 
25 bymeMPTlduringproceasing. Of course, multiple input or output buffers may be used 
pamcularly where me buffer may be providing data to raore ^ one Detwork interfece 
Suntlarly, me input and output memories may be formed within the same single larger 
memory unit or made up of multiple smaller memory units. 

To reduce the delay.from.nianory.read latency, the translator control unit is 
» configured to issue read instructions in a pipelined fashion. In order to mamtain flexibility 
and prnmit new translations tobe performed on existing structures, the translator control uni, 
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Sla that stores the various instnxtions required for all of the translations that the MPT is 
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capable of forming. The stepping through of the instructions performed in the opcode 
memory is controlled by the address control unit 51b. Instructions are fed from the opcode 
memory 51a to a pipeline unit 52. In the embodiment of FIG. 5, the pipeline is implemented 
as a three stage, two-register pipeline. One register pipeline of the two-register pipeline is 
used for opcodes. The other pipeline is used for operands (which are also stored in the opcode 
memory 51a). 

At the beginning of the translation process, the controller 24 of FIG. 2 selects the 
appropriate microcoded instructions stored in the opcode memory 51a for use in the 
applicable translation (i.e., depending on the original and the new protocol for the translation). 
The controller 24 sets the address control 5 1 b to the appropriate start place for the translation 
process. 

The controller 50 takes the opcode information from the pipeline 52 (received from the 
opcode memory 51a) and appropriately sends control signals to the information source 
components for the translated header, e.g., the input memory 53a and the FIFOs 54 and 55. In 
addition, the controller controls the multiplexer, which selects the data being fed to the output 
memory 58 for any given write cycle of the output memory 58. The controller 50 also 
controls what original frame information is recorded in the dump memory 57 and controls 
writing output memory 58 by controlling the multiplexer 56 and the output memory 58 
(including its associated address control). 

The controller 50 can be implemented using discrete components or as part of an 
ASIC or using programmable logic arrays. The controller 50 may also be implemented using 
a general purpose central processing unit, although this level of complexity may not be 
necessary for many implementations. 

The lag time necessary to retrieve information from the various sources that make up 
the translated header can vary. For example, the time required to read from the input memory 
53a may be longer than the time required to read from one of the FIFOs 54 and 55. 
Information coming directly from the translator control unit 59 could be written immediately. 
Thus, the example circuit of FIG. 5 has three different read latencies: input memory (two 
docks), FIFO (one dock), and data written from the controller Cmmwfiate). 

To reduce delays from memory latency, the pipeline 52 has three stages. For an 
opcode indicating data is to be transferred from the input memory to the output memory is 
encountered, the controller issues the appropriate read command to the input memory 53a 
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whcn the opcode is in the first register of the pipeiine in the pipeline unit 52. In subsequent 
stages of the pipeline, that opcode can be ignored, unUl the last stage, where the controller 50 
configures multiplexer 56 to transfer the then-ready data from the input memory 53a to the 
output memory 58. 

5 When data is to be written from one of the FIFO memories 54 and 55, the applicable 

opcode instruction is ignored in the first stage of the pipeline, and the appropriate command is 
issued in the second stage of the pipeiine in the pipeline unit 52 (due to the shorter read 
latency). When the command reaches the last stage of the pipeline, the controller 50 causes 
the multiplexer 56 to transfer the then-ready data from the FIFO to the output memory, 
to Finally, for information to be written directly to the output memory from the operand, 

the applicable opcode is ignored in the first two stages of the pipe, and the applicable write is 
made in the last stage of the pipe in the pipeline unit 52. 

FIG. 6 illustrates a simple circuit design for the pipeline unit 52 of FIG. 5. The 
pipeline is implemented using 8 bit register banks (or latches) 60. The operand is fed through 
15 a first set of registers 62 while the opcode is fed through a second set of registers 61. All of 
the registers 60 are clocked off of a common system clock CLK. Each of the stages of 
opcodes provides information to the controller 50. The operand from the operand pipe 62 is 
directed to the output memory 58, through the multiplexer 56. 

The opcode memory may also effectively be used as an additional stage of the 
20 pipeline. For example, instructions to change the address of the input memory can be taken 
by the controller 50 and used to immediately begin the address change. 

A set of instructions that may be used to program a translation using the multi -protocol 
translator of FIG. 5 is illustrated in the following Table I : 
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Table 1: Single Pipe MPT Instructions 



Name 


Operand 


Description 


READORJG 


no 


Move Byte from input memory to output memory 


READ_ORIG_DUMP 


no 


Move Byte from input memory to dump memory 


R£AD_FIF01 


no 


Move Byte from FIFO! to output memory 


READFIF02 


no 


Move Byte from FIF02 to output memory 


WRITEJM 


yes 


Move operand to output memory 


JUMP_ORIG_DUMP 


yes 


Jump to new OR1G address (per operand value) and 
write to output memory 


JUMPJDPCODE 


yes 


Go to a "subroutine" address in a opcode memory 
space 


RETURNOPCODE 


yes ; 


Return to opcode address + 1 which was stored 
when jump occurred 


RETURNOR1G 


no 


Return to input memory address + 1 which was 
stored when jump occurred 


END 


no 


Tells controller that translation is finished 



The operation of the multi-protocol translator illustrated in FIG. 5 can be understood 
15 in reference to the following example. The example shows conversion from 12 VLAN tagged 
Ethernet dixie (e.g., FIG. 7A) to ATM Forum LANE 2.0 communication protocol (as shown 
in FIG. 7B). 

FIG. 7A illustrates the format of a packet according to the U VLAN tagged Ethernet 
dixie communication protocol A virtual destination address (VDA) and virtual source 

20 address (VSA) are the first two fields 71 of the packet 69. A tag type 72 is included. A 

destination address (DA), source address (SA) and ether type fields 73 arc included. Finally, 
at the end of the packet, is the data or pay load 74. The L2 VLAN tagged Ethernet dixie 
protocol is known to those of skill in the art 

In this example, a packet of the L2 VLAN tagged Ethernet dixie protocol format 

25 illustrated in FIG. 7A is converted to the format of ATM Forum LANE 2.0, as illustrated in 
FIG. 7B. In the ATM Forum LANE 2.0 packet 70 of FIG. 7B, the first field 75 is a fixed 
communication protocol identifier and is the same for every packet formatted according to 
this protocol. An ether-type 76 is included (different from the ether type shown in FIG. 7A). 
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An Elan© and LecID fields 77 are included. 7^ fidds « detennined according to the 
protocol, and, in this example, loaded into the FIFO for the translation. Destination and 

ZOpro to co.incl«d«s. P ayload79at«heend. The payload 79 in the translated packet is 
identical to the payload 74 of the original packet 

. nG - 8 i"^.»methodofusfagam^^ 
the packet of HO. 7A (L2 VLAN tagged Ethernet dixie) into the packet of FIG. 7B (ATM 
Forum LANE 2.0). At a step 80, tf e applicable operation codes (in this case, including 

> ^^^thenanslarionareteadcdintomeopcooememoryS.AofHG^ Thisis 
typically done at initialization, not during translation. 

Block 89 illustrates the normal processing of a packet using one embodiment of a 
muln-^tocoLtranslatora^ 

to receive a packet. Once a packet is received, processing begins a. a step 83. 

At step 83. the packet is loaded into the input memory 53a of the translator 
AtastepHfcecontrcll^rofFlG.y^^ ^ 

» done by examining the protocol of the incoming packet and determining (based on the 

FIFO I 55 of no. 5 is also loaded with the ATM Forum LANE 2.0 ether type, ElanlD and ' 
UdDfieldsfde^rmined by die controller for the applicable packet using methods known m 
the art for this communication protocol). 

In this embodiment, after the applicable translation has been identified, the payload of 
the packet (74 of FIG. 7A) is directly transferred into the output memory 58 of FIG. 5 STEP 
85 (the DMA path is not showD in FIG. 5). 

In this embodiment, while the payload is being transferred from the input to the output 
memory, the multi-protocol translator uni, translate, the header information of the original 
packet into the appropriate header for the translated packet. 

The header translation 88 is performed as illustrated ai steps 86a-86d. 
• • ^sfc^^^tiai^dsofthc^g^ 
M) - ™ 3mayte •"awP&hed either by stepping through these fields of the packet header 
and wnting the information only ,o the dump mcmoiy 57 of FIG. 5. In the alternative, where 
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the information need not be saved, the controller can simply cause the address control 53b of 
the input memory 53a to jump over these fields. 

A. step 86b, the LLC-OU1 header is written to the output memory. In this particular 
embodiment, the LLOOUI field is written directly iron, the opcode memory. That is, a series 
i of microcode instructions write the operand directly from the pipeline unit 52 to the output 
memory 58 of FIG. 5 (through multiplexer 56). Thus, for the LLC-OU1 field (75 of FIG. 7B), 
the enure field is contained as operands in the opcode memory and transferred by directiy 
writing the operands to Ihe output memory. Thus, when the opcode is provided to the pipeline 
unit 52, nothing happens immediately. (However, since it is pipelined, previous and 
subsequent opcodes may be active, depending on the opcode and the stage the opcode is in.) 
Instead, the operand passes through the three stages of the pipeline, with the operand being 
written when the instraction is in the last stage of the pipeline 52. 

At a step 86c, the Ethe, type, ElanID and LecID fields (76, 77 of FIG. 7B) are written 
from FIFOl 55 of FIG. 5 to the output memory 58. In this particular embodiment, the lag 
time of the FIFOl 55 read before the output memory can be written is two clock cycles. 
Accordingly, wh en an instruction from the opcode memory 51a is passed to the pipeline 52, 
calling fo, writing data from FIFOl 55 to the output memory 58. nothing happens at the first 
stage. At the second stage, however, the read command is issued to FIFOl 55. When the 
opcode reaches the last stage of the pipeline unit 52, the data is ready to be read from FIFOl 
to the output memory Accordingly, when that instruction is in the last stage of the pipeline, 
the instruction causes the controller 50 to configure the multiplexer 56 to pass data from 
FIFOl 55 to the output memory 58 and sets up output memory 58 for the appropriate write. 
In the meantime, a new read is issued from the second stage of the pipeline unit 52, to setup 
the next data to be written from FIFO 1 55 to output memory 58. 

Finally, at a step 86d, the DA, SA and Ether type fields of the original packet (field 73 
of FIG. 7A) are transferred directly to the output memory 58 (cotresponding to field 78 of 
FIG. 7B). In this example, the input memory 53a is assumed to have a latency period (in 
clock cycles) longer than the FIFO (two clock cycles rather than one). Accorfingly, when the 
opcode is placed in the pipeline unit 52, a read command is issued at the first stage of the 
pipeline 52. When the opcode corresponding to transfer of data from input memory 53a to 
output memory 58 reaches the last stage of the pipeline 52, the data is ready to be passed from 
the input memory 53a to the output memory 58 (the clock cycles corresponding to the latency 
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of input memory having passed, while the opcode is passing through the pipeline 52). 
Accordingly, when the command reaches the last stage of pipeline 52, it causes the controller 
50 to configure the multiplexer 56 to pass data from the input memory 53a to the output 
memory 58 (as well as enabling writing of the output memory 58). 
5 When steps 85 and 88 are complete, the complete translated packet is in the output 

memory 58 of FIG. 5. Accordingly, at a step 87, the packet can be transferred from the output 
memory to the network interface for propagation to its applicable destination address. When 
this is done, processing may continue at step 82. 

As might be appreciated from the disclosure provided above, the multiplexer 56 of 

10 FIG. 5 should be configured so that the data path into the output memory 58 is open before the 
setup time of the output memory logic, but after the hold time of the multiplexer logic. If the 
sum of the setup and bold time of the multiplexer plus the hold time of the input path plus the 
setup of the output logic exceeds one clock cycle, the multiplexer configuration may be 
performed at an earlier stage (e.g., the second stage) of the pipeline 52. This would make the 

15 multiplexer control logic based on the previous stage rather than decoded from the current last 



In the embodiment of FIG. 5, a one byte channel is used to move information from the 
applicable source (pipeline operand, FIFO memory or input memory) to the output memory. 
The throughput of the translator can be increased by providing for a wider data channel. 

20 FIG. 9 illustrates a multi-protocol translator unit that includes a sixteen bit (two byte) 

data channel, according to the present invention. In the embodiment of FIG. 9, the incoming, 
original packets are stored in input memory 90b, which is controlled by an address control 
90a, as in FIG. 5. The difference, however, is that the input memory can read two bytes of 
information from the data packet. 

25 The translator includes an information memory 91b, controlled by an address control 

91a. Memory 91b stores information to be written into the translated header, and functions 
similar to the FIFO memory illustrated in FIG. 5. A difference, however, is that two bytes of 
information can be read from the reformation memory 91b. 

Uke the input memory 90b and the information memory 9 lb, the output memory 97 

30 can receive two bytes of information. Thus, two single byte channels of information, A and 
B, can be simultaneously written to the output memory. A byte of data from the input 
memory can be provided to the A channel or the B channel of the output memory 97. 
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Multiplexer 92a selects the applicable byte from the input memory 90b or the information 
memory 91b for provision along the A channel to be written in the output memory 97. 
Similarly, multiplexer 92b selects a byte from the information memory or input memory to be 
provided to the B channel of the output memory 97, through multiplexer 95b. Multiplexers 
5 95a and 95b select the data lines for connection to the applicable channel of the output 
memory 97, permitting data to be written from the translator control unit 98c, the input 
memory or information memory data selected by the applicable multiplexer 92a or 92b, or the 
data stored in storage alignment units 93a and 93b. 

The storage alignment unit 93a serves to hold data to be written to the output memory 
.0 97 in later clock cycles. Thus, if information needs to be delayed before being written to the 
output memory, that information can be held for one or more clock cycles in the storage 
alignment unit 93a. This permits data to be held and realigned when written to the output 
memory 97. For example, if a byte becomes available in the data passed from multiplexer 92a 
before the corresponding data to be written in channel B of the output memory 97 is available, 
15 the A channel information can be held and delayed in storage alignment unit 93a. When the 
corresponding byte for channel B of the output memory 97 is available, the.delayed 
information held in storage alignment unh 93a can be written to the A channel of the output 
memory 97, through multiplexer 95a. 

The storage alignment unit 93a includes a multiplexer 96a and a register 96b. In this 
20 particular embodiment, the register is written on every clock cycle. Accordingly, if the data 
needs to be delayed for more than one clock cycle, the data held in 96b needs to be refreshed 
(or maintained) through multiplexer 96a. An example of a translation using the delay units 
93a and 93b is provided below in connection with an embodiment that has four data channels 
that may be written to the output memory at one time. 
25 The control unit 98c has a similar configuration to the control unit 59 of FIG. 5. An 

opcode memory 99b stores the opcodes and operands for controlling the entire translator unit. 
An address control 99a controls the opcodes being read from the opcode memory 99b. The 
opcode memory 99b, however, includes two cjpexxie/operand channels, each sixteen bits wide. 
Trjcttaoj>code/or*iarf^ \fo ^ pipeline unh 52 of FIG. 5. 

30 The second opcode/operand pair is fed to a second pipeline 98a", also like the pipeline unit 52 
of FIG. 5. The two sections 98a\ 98a" of the double pipeline unit 98a permit separate control 
for components used in writing the A channel and B channel of output memory 97. 
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In this embodiment, the double pipeline unit 98a includes two three-stage pipelines. 
In this particular embodiment, three stages were selected to correspond to different latencies 
from the various components that provide data to the output memory 97. Thus, the input 
memory 90b might have one read latency, the information memory 91b a different (e.g., 
shorter) read latency, and the information being written directly from an operand held in the 
last stage of either side of the double pipeline unit 98a having no latency. 

A set of instructions that may be used for the translator unit of FIG. 9 are listed in the 
following table: 



Table 2: 



Name 


Operand 


Description 


R_0RIG_U_A 


no 


read upper Byte lane of input memory and advance 
address controller 


R_ORIG_L_A 


no 


read lower Byte lane of input memory and advance 
address controller 


R_ORJG_U_NA 


no 


read upper Byte lane of input memory and do not 
advance address controller 


R_ORIG_UNA 


no 


read lower Byte lane of input memory and do not 
advance address controller 


PR£LOAD_ORIG_U 


yes 


preload input memory address controller with 
address in operand and read from upper Byte lane 


PRELO A D_ORIG_L 


yes 


preload input memory address controller with 
address in operand and read from lower Byte lane 


RJNFO_U_A 


no 


read upper Byte lane of INFO memory and advance 
address controller 


RJNFO_L_A 


no 


read lower Byte lane of INFO memory and advance 
address controller 


R_INFO_U_NA 


no 


read upper Byte lane of INFO memory and do not 
advance address controller 


R_INFO_U_NA 


no 


read lower Byte lane of INFO memory and do not 
advance address controller 


FRELOAD_INFO_U 


yes 


preload INFO memory address controller wrtb 
address in operand and read from upper Byte lane 


PRELOADJNFO_L 


yes 


preload INFO memory address controller with 
address in operand and read from lower Byte lane 
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Name 


Operand 


Description 


R_BYTE_ STORE 


no 


read byte stored in Delay Unit ~ 


WRITE J M 


yes 


write operand into output memory 


JUMP_OPCODE 


yes 


change the current address of the opcode address 
controller to the operand. Store off current address 
to opcode jump register 


RETURNOPCODE 


no 


change the current address of the opcode to the 
opcode jump register + 1 ; 


STALL 


no 


do not write output memory 


END 


no 


end of algorithm 



Each of the opcode/operand pairs listed in Table 2 can he fed ,o either side of the 

i» 99b wouid include two inanitions of the form listed in Tabic 2 - one for each ride. ,„ 
seiecng b.nary opcodes for these instructs, additional bits are dedicated to signal an 
mdmdual function. One bit signals writing of the output memory $8. Toeotherbit 
controlling reads and writes from an alignment storage unit 93a or 93b. Thus, each of the 
above inanitions has four forms (encoded with the twoexha bfts) - any combination of 

15 commands for writing the output memory (0 or ■) and writing the applicable storage 
alignment unit (0 or 1). 

By inocasing the number of bytes that can be wntten to the output memory per clock 
cycle from one to two (as was done in altering the embodiment of FIG. 5 to FIG 9X the 
throughput of the translator unit can be increased. The number of channels can of course be 
20 increased beyond two. 

FIG. 10 illustrates an embodiment of a translator unit where four channels A, B, C and 
D can be written simultaneously to an output memory 105. 

Like the earlier embodiments, this embodiment has an input memory 1 00b for storing 
me ongmal frame to be translated. The input memory .00b is eontrotled by an address 
" conm>,uni "^ Similarly, infomumon to be inserted into the tmnslated header of the 

translated packet is stored in an infonnauon memory 101b, which is controlled by an address 
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control unit 10 la. Unlike the earlier embodiments, however, four bytes of data can be read 
from each of the input memory 1 00b and inforrnati on memory 101b in one dock cycle. 

A set of four multiplexers 102 permit any of the output bytes of the input memory 
1 00b and information memory 1 0 1 b to be fed along a data channel that feeds any of the four 
5 input channels A, B, C and D of the output memory 105. 

A series of four alignment storage units 103 permit a byte being fed along one of the 
data channels to the output memory to be stored, for alignment with subsequently read data on 
the other data channels. These alignment storage units are of the same configuration as 
described above with respect to the alignment storage units 93a and 93b of FIG. 9. 
io A set of four multiplexers 104 provide the final selection as to what data is actually 

written to the applicable data channel A, B, C, D of the output memory 105 for a particular 
clock cycle. 

A control unit 109 controls the timing and application of data being written to the 
output memory 1 05. Like the earlier embodiments, this embodiment has an opcode memory 
15 106b, controlled by an address control unit 106a Unlike the earlier embodiments, however, 
this opcode memory provides a set of four opcodes, each with an applicable operand. Thus, 
sixty-four bits are provided as an output of the opcode memory 106b. 

These four opcode/operand pairs are provided to a quad pipe. The quad pipe includes 
four pipelines of the type illustrated and described above with reference to pipeline unit 52 of 
FIG. 5. Each opcode/operand pair can perform one or more functions with respect to the 
components in one of the channels providing data to the output memory 105. Thus, because 
four different pipelines are functioning simultaneously, components in all four of the data 
channels can be controlled simultaneously and separately. Because there are three different 
memory latency cycles (one for the input memory, one for the information memory and the 
immediate write of an operand to the output memory through one of the multiplexers 104), 
this pipeline also has three stages. 

A controller 108 takes the information from each of the stages of the pipeline, and 
each of the four pipeline units, and uses that information to provide the appropriate control 
signals for the remainder of the translator unit. 

Table 3 sets forth a set of instructions that may be used to control the translator unit of 
FIG. 10. 
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Table 3: Opcodes 



Name 


Operand 


Description 


R ORlfi R*S a 


DO 


read Byte lane 3 of input memory and advance 
address controller 


«V_ WISJ VJ O Z A 


no 


read Byte lane 2 of input memory and advance 
address controller 


R ORTfi Rl a 


no 


read Byte lane 1 of input memory and advance 
address controller 


R l"M>tn Dn a 
iv_VJivlij_^oU A 


no 


read Byte lane 0 of input memory and advance 
address controller 




no 


read Byte lane 3 of input memory and do not 
advance address controller 




no 


read Byte lane 2 of input memory and do not 
advance address controller 


K UKJO B J _NA 


no 


read Byte lane 1 of input memory and do not 
advance address controller 


R_OR1G_BO_NA 




read Byte lane 0 of input memory and do not 
advance address controller 


PRELOAD_ORJG_B3 


yes 


preload input memory address controller with 
address in operand and read from Byte lane 3 


PREL0AD_0RIG_B2 


yes 


preload input memory address controller with 
address in operand and read from Byte lane 2 


PRELOADJDRIGB 1 


yes 


preload input memory address controller with 
address in operand and read from Byte lane 1 


PRELOAD_ORIG_B0 


yes 


preload input memory address controller with 
address in operand and read from Byte lane 0 


R_INF0_B3_A 


no 


read Byte lane 3 of info memory and advance 
address controller 


R TNFO B2_A 


no 


read Byte lane 2 of info memory and advance 
address controller 


R_INFO_B 1_A 


no 


read Byte lane 1 of info memory and advance 
address controller 


R_INFO_B0_A 


no 


read Byte lane 0 of info memory and advance 
address controller 


R_INF0_B3_NA 


no 


read Byte lane 3 of info memory and do not advance 
address controller 
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Tabic 3: Opcodes 



Name 


Operand 


l|IIIUU 


R_rNF0_B2_NA 


no 


read Byte lane 2 of info memory and do not advance 
address controller 


R_lNFO_B1_NA 


no 


read Bvte lane 1 of info mnnnrv anH Ar\ nn* 

j kw j ui uiju uicLiiwiy oiiu tiu noi aovancc 

address controller 


RIN F0_ B O N A 


no 


read Byte lane 0 of info memory and do not advance 
address controller 


PRELOAD_INFO_B3 


yes 


preload info memory address controller with address 
in operand and read from Byte lane 3 


PRELOADJNFOB2 


yes 


preload info memory address controller with address 
in operand and read from Byte lane 2 


PRELOADJNFOBl 


yes 


preload info memory address controller with address 
in operand and read from Byte lane 1 


PRELOAD JNFO_B0 


yes 


preload info memory address controller with address 
in operand and read from Byte lane 0 


R_BYTE_STORE 


DO | 


read byte stored in Alignment Storage 


WRITE JM 


yes 


write operand into output memory 


JUMP_OPCODE 


yes 


change the current address of the opcode address 
controller to the operand. Store off current address 
to opcode jump register 


RETURNOPCODE 


no 


change the current address of the opcode to the 
opcode jump register + 1 ; 


STALL 


no 


do not write output memory 


END 


no 


end of algorithm 



As above, each of these opcodes applies to each of the data channels A, B, C, D of the 
output memory. Thus, the opcodes of Table 3 apply to just one of the channels, and each read 
from the opcode memory would produce four of such opcodes. In addition, like above, two 
extra bits for each opcode encode whether one or both of the output memory or applicable 
storage alignment unit is written. 

Operation of the circuit of FIG. 1 0 can be understood through the following example. 
This example converts the L2 VLAN lagged Ethernet dixie packet illustrated and discussed 
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information memory 101b to the output memory 105. Accordingly, the control unit (not 
shown) configures the appropriate multiplexers 104 to pass the information directly into the 
output memory 105. As shown within the box illustrating information memory 101b, the two 
bytes of the Ether-type are stored in bytes "0" and"]" of the four byte word stored in the 
information memory 101b. Thus, the illustrated connection transfers the Ether-type bytes to 
the output memory 105. 

FIG. 1 2B illustrates the packet as stored in the output memory 105 after the step 
illustrated in FIG. 12A takes place. As shown, the leading header and Ether-type have now 
been written to the output memory 105, as shown at 125. The remainder of the translated 
packet 126 has not yet been written to the output memory 105. 

FIG. 1 3 A illustrates the next step in the translation. At this point, the two most 
significant bytes for the EJanlD field are stored in a four byte word in the information memory 
101 b, as shown. These two bytes cannot be written directly to the output memory, however, 
because the output memory requires a four byte word to be written. Accordingly, the two 
bytes of the ElanJD need to be stored in the storage alignment units 103, for later writing to 
the output memory 105. This is done as illustrated in FIG. 13 A. During this clock cycle, no 
information is written to the output memory. Accordingly, the output memory continues to 
hold the same partially translated packet of FIG. I2B. 

At the step illustrated in FIG. 13 A, the other two pipelines hold two instructions that 
require reading of information from the input memory 100b - jump orig B0 at 131a (which 
causes the input memory 100b to jump to an operand address - to cause the address controller 
(not shown) of the input memory 100b to skip over the portions of the original packet header 
that are not used in the translated packet, i.e., fields 71 , 72 of FIG. 7A). By changing the 
address of the input memory 100b, the next portion of the header to be read can be moved to 
an address that skips (deletes) fields 71, 72 of FIG. 7A (deletes the VDA, VSA and TAG type 
fields). In this particular embodiment, the read latency of the input memory 100b is longer 
than the read latency of the information memory 101b. When instructions involving reading 
of the input memory 100b reach the first stage 1 10 of the pipdir* unit (at 131aand 131b), the 
control unit (not shown) causes the input memor>'*s address control unh 1 00a to apply the 
applicable address and initiates a read of the input memory 100b. 

FIG. 14A illustrate the next clock cycle in this translation. At this step, the remainder 
of the ElanJD field is present at bytes 0 and I of the information memory 101b. Accordingly, 
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Pipclines with three stages and having a width of! , 2 and 4 pipelines have been 
described. Pipelines of varying numbers of stages and varying widths can be constructed. 
Moreover, the example opcodes are illustrative only. Any number of other byte 
manipulations could be implemented- Finally, because the translator circuit structure may be 
built from common components, circuit design lends itself to automated procedures, including 
automated circuit design and optimization. 

Having thus described at least one illustrative embodiment of the invention, various 
modifications and improvements will readily occur to those skilled in the art and are intended 
to be within the scope of the invention. Accordingly, the foregoing description is by way of 
example only and is not intended as limiting. The invention is limited only as defined in the 
following claims and the equivalents thereto. 

What is claimed is: 
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CLAIMS 

1 A translator unit for translating a first packet formatted according to a first protocol 
having a first header format into a second packet formatted according to a second protocol 
having a second header format different from the first header format, the translator unit 
s comprising: 

an input memory; 

at least one information source; 

an output memory; 

a connection circuit, coupled to the input memory, the information source and the 
10 output memory, to selectively connect the input memory and the information source to the 
output memory; and 

a microcoded control unit coupled to the connection circuit to control translation of the 
first packet into the second packet. 



15 



2 The translator unit of claim 1 , wherein the information source is selected from the 
group consisting of a register, a FIFO memory, a random access memory and an opcode 
memory storing data as operands of microcoded instructions. 



3 The translator unit of claim I, wherein the microcoded control unit includes a pipeline 
20 unit 

4 The translator unit of claim 1 , wherein the microcoded control unit includes two 
pipeline units. 
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5 The translator unit of claim 4, wherein: 

the output memory includes at least two inputs to simultaneously write at least two 
bytes of data into the output memory; and 
5 the connection circuit includes means for aligning the two bytes of data to be 

simultaneously written into the output memory. 

6 The translator unit of claim 1 , wherein the microcoded control unit includes four 
pipeline units. 

10 

7 The translator unit of claim 6, wherein: 

the output memory includes at least four inputs to simultaneously write at least four 
bytes of data into the output memory; and 

the connection circuit includes means for aligning the four bytes of data to be 
i s simultaneously written into the output memory. 

8 The translator unit of claim 1, further comprising a direct memory access controller 
coupled to the input memory and the output memory. 

20 9 The translator unit of claim 1 , wherein the microcoded control unit includes an 
opcode memory programmed to perform multiple different protocol translations. 

1 0 A pipelined control unit for reading data, comprising: 
a first memo ry having a frrct read latency; 
25 a second memory having a second read latency, longer than the first read latency; 
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a pipeline unit having a first stage and a second stage; 

a circuit, coupled to the pipeline unit, the fust memory and the second memory, to 
inmate read cycles from the first memory based on a first instruction in the second stage of 
5 the pipeline, and to initiate read cycles from the second memory based on a second 
instruction in the first stage of the pipeline. 

11 ^jripelmed control unit of claim 10, further comprising a microcontroller coupled 
to the circuit 

10 

12 A method of translating an original packet from a first protocol to a different second 
protocol, comprising steps of 

loading a first memory with a plurality of sets of microcode instructions, each set 
being designed to perform a different network communication protocol translation; 
15 receiving the original packet and storing the packet in an input memory; 

selecting one of the sets of microcode instructions, based on a first identity of the first 
protocol and a second identity of the second protocol; and 

translating the original packet into a translated packet by executing the selected set of 
microcode instructions, said translating step including a step of selectively connecting the 
20 first memory and the input memory to an output memory. 

13 The method of claim 12, wherein the translating st ep includes a step of feeding the 
selected set of microcode instructions through a pipeline. 
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14 A method of translating an original packet into a translated packet that is different 
from the original packet, comprising steps of: 

loading an instruction memory with a set of instructions; 

loading at least a header portion of the original packet into an input memory, the input 
memory having a first read latency; 

providing an information source; 

providing an output memory to store the translated packet; and 
sequentially, selectively connecting the input memory and the information source to the 
output memory, based on the set of instructions. 

15 The method of claim 14, wherein the set of instructions are microcoded instructions. 

16 The method of claim 14, wherein the connecting step comprises a step of feeding the 
set of instructions through a pipeline unit 

1 7 The method of claim 1 6, wherein: 

the pipeline unit has a plurality of stages; 

the set of instructions includes a first instruction to read information from the input 
memory and write the information to the output memory, and a second instruction to read 
information from the information source and write the information to the output memory; and 

the connecting step comprises steps of 

initiating reads from the input memory when the first instruction is one of the 

pipeline stages selected based on the Jirst rrad lazncy; and 
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3i: 

initiating reads from the information source when the second instruction is one 
of the pipeline stages selected based on the second read latency. 



1 8 The method of claim 17, wherein the connecting step comprises a step of connecting 
the input memory to the output memory when the first instruction reaches a one of the 
pipeline stages after the pipeline stage where the first instruction initiated reading of the input 
memory. 

19 The method of claim 14, further comprising a step of transferring a payload portion of 
the original packet from the input memory to the output memory using a direct memory 
access controller. 

20 The method of claim 14, wherein: 

the connecting step includes a step of connecting a plurality of data channels to the 
output memory. 

2 1 The method of claim 20, further comprising a step of storing data in an alignment 
storage unit to align data on the data channels to be simultaneously written to the output 
memory. 



-32- 

22. A translator unit substantially as herein described with reference to Figs. 
2 to 15 of the accompanying drawings. 

23. A pipelined control unit substantially as herein described with reference 
5 to Figs. 2 to 1 5 of the accompanying drawings. 

24. A method of translating substantially as herein described with reference 
to Figs. 2 to 15 of the accompanying drawings. 



10 DATED: 28 April, 2000 

PHILLIPS ORMONDE & F1TZPATRICK 
Attorneys for 

CABLETRON SYSTEMS INC. 
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